Mobile Malware Evolution: An Overview, Part 1

1. Mobile Malware Evolution: An Overview, Part 1
2. Mobile Malware Evolution: An Overview, Part 2

June 2006 was a historic month: it marked two years since Kaspersky Lab obtained the first sample of a virus for mobile phones. Although it wasn’t clear initially, we now know that the virus was written by ‘Vallez’, a member of the international group of virus writers known as 29A.

This first sample opened Pandora’s Box. Antivirus companies now have hundreds of Trojans and worms for mobile phones in their collections. The trickle of new malicious programs for Symbian that began in 2004 has become a constant stream which threatens to become a torrent. Every week about ten Trojans with the “SymbOS” prefix are added to our antivirus databases.

In itself, this might not seem like anything major. However, the worst thing is that worms for mobile devices are causing more and more outbreaks, and it’s not possible to assess the true scale of these outbreaks yet. A year ago, the only news we were getting of Cabir was that it had been detected in yet another country or city. Then owners of infected phones started contacting Kaspersky Lab directly and we started dealing with real infections, including some employees at Kaspersky Lab HQ in Moscow.

It may be that mobile worms are spreading so fast because an average mobile phone user is less security conscious than an average Internet user. On the other hand, even long time mobile users treat mobile malware as a problem which hasn’t happened yet, or believe that it’s not an issue which really concerns them.

But mobile viruses don’t exist in some parallel world. They are part of the here and now, and every time you go on public transport, to the cinema or the airport your mobile phone is potentially under attack.

There’s a long way to go before users know as much about mobile viruses as they do about computer viruses…

In the Beginning Was Cabir…

On June 14, 2004, a well-known Spanish virus collector known as VirusBuster, who had close links with some virus writers, sent a message to ‘newvirus@kaspersky.com’. The message had a file called caribe.sis attached. At the time we weren’t sure what we were dealing with – we’d never seen anything like it before. A quick analysis showed that it was an application for Symbian OS and also an installer archive containing other files. As a rule, virus analysts deal with files created for traditional x86 processors. The files in caribe.sis were applications for ARM, processors which are used in a range of devices, including mobile phones. Initially, we knew very little about the machine language used by that processor, but within a few hours our analysts had managed to familiarize themselves with it. The purpose of the files was then clear: this was a worm for mobile phones which spread via Bluetooth. Our conclusions were fully confirmed the next day when we tested the worm on a Nokia N-Gage telephone running Symbian.

The worm was written by someone going under the name of Vallez. As far as we know, he lives in France and was, at the time, a member of a group of virus writers called 29A. The group’s aim was to create proof-of-concept virus code for non-standard operating systems and applications. The group’s members seemed determined to demonstrate to antivirus companies and other virus writers that there were new, previously unexplored infection vectors. Back in June 2004, the objective was to create a malicious program for smartphones. The author also chose a non-standard replication method – analysts are used to worms which spread via email, and Cabir could have been expected to propagate in the same way, given that Internet connectivity and email are two of the main features of smartphones. However, the worm’s author chose Bluetooth instead; an approach that turned out to be key.

Cabir is coded for the Symbian operating system, which was, and remains, the most commonly used operating system in mobile phones. This marker leader position is due largely to the fact that all smartphones produced by Nokia are Symbian-based. In fact, Symbian+Nokia is currently the standard smartphone combination, and it’s going to take Windows Mobile a long time to win a significant share of the market from Symbian.

The appearance of Cabir confirmed the law of computer virus evolution. In order for malicious programs targeting a particular operating system or platform to emerge, three conditions need to be fulfilled:

1. The platform must be popular. Symbian was and remains the most popular platform for smartphones, with tens of millions of users throughout the world.

   Cabir’s author: “Symbian could be a very extended operating system used in mobile phones in the future. Today is the more extended and in my opinion it could be more yet (M$ is fighting too for being into this market too).”

2. There must be well-documented development tools for the application.

3. Cabir’s author: “Caribe was written in c++. Symbian/nokia is giving us a complete sdk for developing applications for symbian operating system.”

4. The presence of vulnerabilities or coding errors. Symbian includes a number of faults, by design, in the system that handles files and services. In the case of Cabir these faults were not exploited, but most of today’s Trojans for smartphones take full advantage of them.

Cabir immediately attracted the attention not only of antivirus companies, but of other virus writers as well. The latest issue of 29A’s webzine was eagerly awaited, with the expectation that the group would, in accordance with tradition, publish the worm’s source code. Naturally, the publication of the source code would lead to the emergence of new, more harmful variants of the worm: this is what always happens when script kiddies gain access to such technologies. However, petty cyber criminals can be capable of doing a lot of damage even without access to original source code.

Current mobile malware types and families

Autumn 2004 was when mobile malware started to evolve in three main areas. One was Trojan programs which are designed for financial gain. The first mobile Trojan was Mosquit.a. In theory, it’s a harmless mobile phone game; however, at some point it starts to send numerous SMS messages to telephone numbers in the address book, meaning that the user’s phone bill will increase. In fact, Mosquit.a wasn’t only the first Trojan for smartphones, but also the first piece of adware for mobiles.

Skuller.a, a Trojan which appeared in November 2004, was the first of what is now the largest family of mobile Trojans. This was the first malicious program to take advantage of the design faults of Symbian, which make it possible for any application to overwrite system files with their own files without prompting the user. Skuller replaced application icons with skull and crossbones, and also deleted application files. As a result, the handset would stop working once it had been switched off and switched on again. This type of “vandal Trojan” became one of the most popular among virus writers.

Three new variants of Cabir appeared practically at the same time as Skuller.a. These new variants were not based on the source code of the original worm. By this time virus writers had got their hands on Cabir, and some of them did what script kiddies do: they renamed the worm files and replaced some of the text in the files with their own. One variant added Skuller to the original archive. The resulting hybrid didn’t function as intended: the worm was unable to replicate because the Trojan crashed the phone. However, this was the first time that Cabir was used as a carrier for other malicious programs.

By the beginning of 2005, the main types of mobile malware had evolved, and were used by virus writers over the next eighteen months:

• worms that spread via smartphone protocols and services
• vandal Trojans that install themselves to the system by exploiting Symbian design faults
• Trojans designed for financial gain

However, although there are only a few main types of behavior, in practice mobile malware comes in a variety of forms. Kaspersky Lab is currently tracking 31 distinct mobile malware families. The table below shows the main characteristics for each family.

The increase of known mobile malware variants

Increases in known mobile malware families

In short, the table answers the question “What can mobile viruses do?”:

• Spread via Bluetooth, MMS
• Send SMS messages
• Infect files
• Enable remote control of the smartphone
• Modify or replace icons or system applications
• Install “false” or non-operational fonts and applications
• Combat antivirus programs
• Install other malicious programs
• Block memory cards
• Steal data

We have to acknowledge that today’s mobile viruses are very similar to computer viruses in terms of their payload. However, it took computer viruses over twenty years to evolve, and mobile viruses have covered the same ground in a mere two years. Without doubt, mobile malware is the most quickly evolving type of malicious code, and clearly still has great potential for further evolution.

The Basics

One of the main differences in the technology used in viruses for mobile devices and personal computers is that, although there are numerous mobile virus families, very few mobile viruses are truly original. This is similar to computer viruses in the late 1980s. Back then, there were hundreds of viruses derived from the source code of “base” malicious code. A multitude of malicious programs were based on just three viruses: Vienna, Stoned and Jerusalem.
In terms of mobile malware, I would identify the following programs as the “forebears” of other mobile viruses:

• Cabir
• Comwar
• Skuller.gen

Cabir served as the basis for a number of its own variants, which differ only in terms of the file names and the contents of the sis installation files. Cabir was also used as the basis for such seemingly dissimilar families as StealWar, Lasco and Pbstealer.

Lasco

Lasco was the first of these “new” families to appear. In addition to worm functionality, programs from this family are capable of infecting files in the phone memory. Lasco’s evolution is a good example of what happens when virus source code is made publicly available. A Brazilian by the name of Marcos Velasco, who calls himself a mobile virus expert, got hold of the source code for Cabir and began writing viruses. During the last week of 2004 he sent several variants of Cabir that he had written to antivirus companies. Some of them were completely non-operational and all were categorized as Cabir variants. This did not please the author; in an attempt to become famous he created a variant of the worm that was also capable of infecting sis files. This is how the Lasco worm came to be in antivirus databases.

Luckily, the idea of infecting files was not further developed by virus writers, even though Velasco published the source code of his creation on his website.
It is still not quite clear whether Cabir was actually used as a source for Lasco. According to Marcos Velasco, he wrote all the code independently, but the number of files, their names and operating principles are very similar to Cabir. It’s possible to compare the main functions in both worms and draw your own conclusions.

The function that sends the worm via Bluetooth (Cabir):

Pbstealer

The first Trojan spy for Symbian, Pbstealer, is another Cabir “offspring”. It was created in Asia, probably in China, and was found on a hacked Korean website devoted to Legend of Mir, an online game. This method of distribution and the fact that the Trojan was written with criminal intent demonstrates how the “good intentions” of Cabir’s author paved the way for the development of further malware.

The function that enabled the Trojan to send files via Bluetooth came from Cabir. However, authors of the Trojan made one important modification to the original code. The Trojan searches for the phone’s address book and sends data contained in it via Bluetooth to the first device found. Hence the name Pbstealer, which stands for “Phonebook Stealer”. Until then cybercriminals used various vulnerabilities in the Bluetooth protocol to steal such information, e.g., BlueSnarf. This Trojan, however, greatly extended the possibilities available.

And, of course, Cabir became the carrier of choice for a variety of other Trojans. More than half of all Skuller, Appdisabler, Locknut, Cardtrap and other “vandal” Trojan variants contain Cabir, which has been modified to spread not only itself, but the whole Trojan package. This sort of hybridization has led to significant difficulties in categorizing many malicious programs. We will discuss this in greater detail below.

Comwar

A second landmark in the development of mobile malware was Comwar, the first worm to spread via MMS. Like Cabir, it can spread via Bluetooth, but MMS is the principal method used, making this worm potentially extremely dangerous.
Bluetooth operates within a distance of 10 to 15 meters and other devices can be infected only if they are within this range. MMS has no boundaries and can be instantly sent even to handsets in other countries.

The author of Cabir initially considered this idea, but chose Bluetooth for quite obvious (from the viewpoint of 29A ideology) reasons:

The second reason is telling: it means that the author of Cabir did not wish to do financial harm to users. The author of Comwar, on the other hand, had no qualms about this whatsoever.

Although the technology that makes it possible to send malware via MMS is the most attractive to the authors of mobile malware, so far we’ve only seen the usual transformations performed on the original worm, with baby hackers changing file names and texts in the original files without making any changes to Comwar’s functionality. This is due to the fact that the source code for Comwar has not been published and the script kiddies don’t know the procedure used to send infected MMS messages.

Currently, we know of 7 modifications of this worm. Four of them include an “author’s signature”.

Comwar.b:

Comwar.c:

Comwar.d:

Does not contain any distinguishing texts. MMS texts replaced with Spanish texts.

Comwar.e:

Also contains texts in Spanish.

Comwar.f:

Does not contain any distinguishing texts. MMS texts replaced with Spanish texts.

Comwar.g:

In addition to the above, variant .g was the first variant to include file infector functionality. The worm looks for other sis files in the phone’s memory and appends its code to these files. This provides one more propagation method in addition to the traditional MMS and Bluetooth.

It should be noted that so far Comwar has not spawned a multitude of other families. As mentioned above, the reason for this is that its source code has not been published. Just like Cabir, it is used as a carrier for other Trojan programs. Apparently, the only program using Comwar that can lay claim to having started a new family is StealWar. This is a worm that combines Cabir, Comwar and the Trojan Pbstealer. This type of combination is highly dangerous and capable of spreading widely.

However, it’s inevitable that propagation via MMS will eventually become the most common method of propagation for mobile malware. This is all the more likely because there is already a serious known MMS handling vulnerability in Windows Mobile 2003, which leads to a buffer overflow and the execution of arbitrary code. The vulnerability was reported by Collin Mulliner in August 2006 at the DefCon conference.

Demonstration of the MMS vulnerability(Collin Mulliner, Advanced Attacks Against PocketPC Phones).

Detailed information about the vulnerability will not be available to the general public until Microsoft releases the relevant update. However, the absence of information doesn’t make the vulnerability any less dangerous. If somebody creates a worm that launches itself automatically, without the user’s participation when it gets into a smartphone memory, this could cause a global outbreak.

Comwar also contributed to the evolution of mobile malware with a technology implemented in variant .c; this technology could be seen as rootkit technology. The worm conceals itself in the list of processes and is not visible in the standard list of applications currently running. Comwar is able to do this because its process is designated as “system”. Although the process can easily be discovered using other programs for viewing running processes, this masking method is nevertheless now being used in some other malicious programs for Symbian.

Skuller

As mentioned above, Skuller is the most numerous family of mobile Trojans: by September 1st, 2006 we had seen 31 variants. This is not surprising, as these programs are the most primitive malicious programs for Symbian. Any person who can use a utility for creating sis files will be able to create a Trojan of this kind. The rest of the work is done by the vulnerabilities present in Symbian: it is possible to overwrite any files, including system files, and the system becomes very unstable when it comes across unexpected files (i.e. files that are damaged or not standard format for the relevant version of the system).

Most Skuller variants are based on two files, which we classify as Skuller.gen, and it’s these files that distinguish Skuller from other families with similar functionality (e.g., Doombot or Skudoo):

• a file with the same name as the application it replaces and the extension “aif”. Its size is 1601 bytes. This is an icon file containing the skull icon. The file also contains the following text string: “↑Skulls↑Skulls”;
• a file that has the same name as the application it replaces and the extension “app”. Its size is 4796 bytes. This is an EPOC application, a stub file.

The problems of classification

One of the main issues in contemporary mobile malware research is classification; specifically, labeling new samples correctly and grouping them into the appropriate classes that reflect their behavior. The main difficulty is that most new malicious programs for mobile devices are hybrids, containing functionality from two or more different types of malware.

The Kaspersky Lab classification system is clearly structured:

• Behaviour: this shows what the program is, and what it does. Examples include Email-Worm, Trojan-Downloader, Trojan-Dropper.
• Environment – i.e. the operating system or specific application within which the malicious program functions. Examples include Win32, MSWord, Linux, VBS
• The family name and the variant identifier (letters).

There are few, if any, problems when it comes to the family name and variant ID. Occasionally it is difficult to choose a family name, but this is discussed in more detail below.

Sometimes it is difficult to identify the environment. Currently, most cases of mobile malware involve malicious programs written for the Symbian operating system, which we denote with “SymbOS”. However, more and more frequently users are wanting to know which particular Symbian Series a particular piece of malware is coded for. “Will a given Trojan only function in Symbian Series 60 SE, or will it also attack devices running under Series 80?”, and so on. In our classification system for computer malware, we do identify the specific Windows version: Win16, Win9x, Win32. So it’s possible that in future we will need to include numbers in our Symbian classification as well.

In terms of mobile malware, identifying the Symbian series is the least of our problems. Things get much more complicated when we examine Windows Mobile.

For instance, there are viruses that were written for Windows CE 2003. We named this environment WinCE. However, malware written for Windows Mobile 5.0 doesn’t function under Windows CE. Moreover, Windows Mobile does not fully replace Windows CE, since we also have Windows Pocket PC. Mobile and Pocket PC both use a set of functions which are also used by Windows CE, but then have their own specific applications and peculiarities.

As a result, it is very difficult to use the existing classification system to give a specific piece of malware a precise name that reflects its behavior.

Additionally, a number of viruses require that .NET for WinCE/ Windows Mobile be installed in order for them to function. In such cases, we use the designation MSIL for the environment, which does not underline the fact that the malware was coded for mobile devices.

Confused yet? This is just the tip of the iceberg. The most complicated part of naming mobile malware is choosing the behavior. This is where serious complications are caused by hybridization, as well as cross platform mobile malware and the different naming conventions used by different antivirus vendors.

A look at some examples will make the issue clearer.

Let us assume that we have a certain sis file (which in essence is an archived installer). This file contains the files from Cabir, Comwar, the Pbstealer Trojan, several Skuller.gen files and several empty files (0 bits), which are a hallmark of Locknut. And if this wasn’t enough, this file also installs a Win32 virus to the phone’s memory card (just like the Cardtrap Trojan).

Based on our current classification system, we would call this a Trojan-Dropper. But not in this case! Cabir, once installed, will send the sis file via Bluetooth. Does this mean the sis file is a worm? And if so, what do we call it? Cabir? Impossible. We can’t call it Cabir and give it a new variant ID because 90% of the sis file contents have nothing to do with Cabir. Naming it Cabir would only confuse users.

What about Skuller, Locknut or Cardtrap? But none of these names alone are applicable, since the new sample is a hybrid. As a result, the sis file is most likely to be called a Trojan and given a family name of an existing family from our collection. This name will be chosen on the basis of secondary traits, such as being written by the same author.

Such complex situations are rare for computer viruses, but are the norm for mobile malware. It’s possible that as primitive vandal Trojans become fewer, (as mentioned above) as described above, the world of mobile malware will become more structured.

Let’s examine another case. We have a worm that runs under Win32. When it is launched on a PC, among other things, it creates a sis file on the E: drive. As a rule, Symbian phones connect to PCs via this drive. The sis file contains several blank/empty files and these are used to overwrite a number of the phone’s system applications. This sis file also contains the same Win32 worm, which copies itself onto the phone’s memory card together with an autorun.inf file. If the infected phone is connected to a clean computer and an attempt is made to access the memory card from the PC, the worm will be launched and the clean computer infected.

This is an example of a cross-platform virus which is capable of running under two operating systems: Symbian and Windows. A worm like this exists – it’s called Mobler. But how should it be classified?

For cross-platform viruses, we used the “Multi” identifier. Worm.Multi.Mobler? Unfortunately, users can’t tell from this name that the virus poses a threat to Symbian smartphones. We believe that the best way to classify this program is in accordance with its two components: the win32 file is classified as Worm.Win32.Mobler, and the sis file as Worm.SymbOS.Mobler.

However, other antivirus companies don’t classify the sis file either as Mobler, or as a worm. They call this program Trojan.SymbOS.Cardtrap, because, according to their classification systems, any malicious program which installs a Win32 malicious program to the memory card is Cardtrap. But this malicious program doesn’t install a random Trojan, it installs its own main component and sends a copy of itself only to other operating systems. However, the strict criteria imposed by antivirus companies’ classification mean that the square pegs have to be forced into round holes. And at the end of the day this means everybody loses – both the users and the antivirus companies themselves.

If we start from the assumption that the propagation methods and behaviours of many mobile viruses will be fundamentally different from anything we’ve seen before, this means that we will have to create new classes in order to reflect this. For instance, Cabir (or any worm which propagates via Bluetooth) could logically be classified as a Bluetooth-Worm (as could Inqtana, a worm for Mac OS). A worm which propagates via MMS could be classified as an MMS-Worm. But what if the worm sends itself via Bluetooth and via MMS? Which of these two propagation methods is the most important? Kaspersky Lab would see MMS as being the main propagation methods, but other antivirus companies might think differently, giving priority to Bluetooth.

Sooner or later the antivirus industry will have to face the fact that it’s essential to create a unified classification system for mobile malware. This should be done as soon as possible before the situation becomes critical, and before the confusion that reigns in terms of classifying PC viruses (with viruses being given totally different names by individual vendors) takes over the mobile malware world. Unfortunately, the failure to create a unified classification system for PC viruses does not leave much hope for the future in terms of mobile malware classification.